home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 1339 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.8 KB
  1. Path: mips.pfalz.de!not-for-mail
  2. From: naddy@mips.pfalz.de (Christian Weisgerber)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: Question about Error Correction and Compression
  5. Date: 13 Jan 1996 01:16:20 +0100
  6. Message-ID: <4d6tkk$npr@mips.pfalz.de>
  7. References: <4csame$orf@hermes.acs.unt.edu>
  8. NNTP-Posting-Host: mips.pfalz.de
  9.  
  10. bryon@jove.acs.unt.edu (Bryon Sutherland) writes:
  11.  
  12. > Many different applications are timing dependant and need error correction 
  13. > and compression turned off,
  14.  
  15. "Many" is arguable. Anyway, are you sure *your* applications are among
  16. those?
  17.  
  18. > but it seems logical to me that only one modem (on the server end
  19. > preferably) needs to have them turned off.  
  20.  
  21. Basically right.
  22.  
  23. > Won't the modem that's dialing in talk-down to the serving modem and not 
  24. > use error correction and compression?
  25.  
  26. If not configured to behave otherwise, yes. A potential problem is that
  27. error control is negotiated in-band, and the negotiation is initiated by
  28. the caller. Assuming that the modem is a modern one with V.42, and
  29. configured for "auto-reliable mode" (a fair assumption nowadays) the
  30. following will happen:
  31.  
  32. 1. The calling modem will try to establish a V.42/LAPM connection. It
  33.    will send a stream of XONs of alternating parity (i.e. 0x11 0x91 0x11
  34.    0x91 ...) and wait for an acknowledging "EC".
  35.  
  36. 2. If it doesn't receive a response, the modem will try to establish a
  37.    connection according to the V.42 "Alternative Procedure", better
  38.    known as MNP. For this is will send an MNP LR frame, i.e. a bunch of
  39.    binary garbage characters.
  40.  
  41. 3. If it doesn't receive an MNP LA frame in response, the modem will
  42.    give up and run the connection without error control.
  43.  
  44. Note that different brands of modems show different degrees of
  45. cleverness and persistence for this negotiation, both at the calling and
  46. answering end. Steps (1) and (2), respectively, are usually repeated a
  47. few times each before falling back to (2) and (3), respectively. Modems
  48. with MNP10 will be more aggressive in their attempts to establish an
  49. error control link.
  50.  
  51. I *think*, answering USR Couriers with error control disabled (&M0) will
  52. try to abort incoming requests for error control (answering "E\0" at
  53. step (1) etc.) as quickly as possible.
  54.  
  55. > If I could set my servers modems that way I wouldn't have to worry about 
  56. > each of 300 users properly configuring their modems, right?
  57.  
  58. From the description above, it should be clear that at the answering
  59. end, with error control off, you'll receive a stream of garbage
  60. characters and it will take the calling modem a few seconds to fall
  61. back. Data sent during this time to the caller may be lost. Whatever
  62. your applications are, they'll have to deal with all this.
  63.  
  64. Many years ago, when I was new to modems, networking, etc., I
  65. participated in a small German BBS network (MagicNET, for those German
  66. readers who remember). The BBS software we used prompted the caller to
  67. press return, ostensibly to determinate the parity type used, before
  68. continuing with the login. If, however, a special character, I think it
  69. was ^F, was entered instead of a carriage return, the BBS would drop
  70. into netcall mode, which would't allow a user login anymore. (Yes, all
  71. of the design was utterly braindead. It wasn't mine, but I'll admit that
  72. I wouldn't have known better back then, for that matter.)
  73.  
  74. When modems featuring error control became popular, it turned out that
  75. their MNP negotiation attempts always caused the BBS to drop into
  76. netcall mode, if it didn't have an MNP-capable modem itself. This caused
  77. a lot of confusion until people realized they had to disable error
  78. control. Due to the limitation of the BBS software and netcall protocol,
  79. their was nothing that could be done at the answering end.
  80.  
  81. -- 
  82. Christian 'naddy' Weisgerber                         naddy@mips.pfalz.de
  83.   See another pointless homepage at <URL:http://home.pages.de/~naddy/>.
  84.         -- currently reading: John Norman, Dancer of Gor (#22) --
  85.